Powszechnie znaną prawdą jest, iż niewielu z nas przejmuję się wydajnością naszego kodu, jeszcze mniej z nas miało do czynienia z testami wydajnościowymi. Wśród tych z nas, którzy toczą nierówną walkę z wydajnością, wąska garstka z nas jest świadoma jak wiele kryję się w nich kłamstw, niedomówień i fałszywych obietnic. Podczas prezentacji poznamy antywzorce w testowaniu wydajności oraz kilka sprawdzonych w boju praktycznych rad jak nie dać się omamić wynikom testów.
Jarosław Pałka Software Consultant/Architect/Trainer
Od ponad 20 lat w branży IT, jako administrator baz danych, programista, architekt, manager i „inżynier od spraw katastrof”. Brałem udział w małych, średnich i nonsensownie dużych projektach, prowadzonych zgodnie zasadami „waterfall”, Agile oraz przy braku jakichkolwiek metodyk, z tym samym zawsze skutkiem. Co doprowadziło mnie do wniosku, że nieważne co robisz tak długo, jak robisz to dobrze, w najprostszy z możliwych sposobów i używasz właściwych narzędzi, które wykonają pracę za ciebie. W międzyczasie dałem się porwać ideą TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL, by potem porzucić je, by zgłębić tajniki „system thinking” i zachwycić się siłą jaką niesie z sobą „metafora” i odkryć, że rządzą nami te same prawa „natury”. Niepokorny wyznawca kościoła JVM, badacz bytecode’u i JIT oraz wszelkiej maści parserów, interpreterów i kompilatorów. Na co dzień walczący o lepszą wydajność w Neo4j. Od czasu do czasu można usłyszeć moje niskiej jakości żarty na temat architektury na konferencjach w Polsce. W wolnych chwilach trener w http://symentis.pl i autor bloga na http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w radach programowych konferencji.
Skąd wiesz czy piszesz dobry kod?! Bo jest zgodny z konwencjami? Bo statyczna analiza nie wykrywa błędów? Bo przestrzega SOLID, CUPID, DRY, KISS?
Wszystkie te kryteria są niesamowicie subiektywne, bo czy zgadzamy się wszyscy czym jest pojedyncza odpowiedzialność, albo ile linii ma krótką metoda, czy dana klasa wystarczająco enkapsuluje?
I tu pojawia się pytanie, czy da się obiektywnie oceniać kod? W 100% raczej nie, ale da się dużo bardziej niż do tej pory.
Łukasz Szydło
Programista pasjonat, fan “Software Craftsmanship” i zwinnego podejścia do wytwarzania oprogramowania.
Lubi proste rozwiązania skomplikowanych problemów. Na codzień zajmuje się tematami z zakresu architektury aplikacji biznesowych, Domain-Driven Design, Continuous Delivery, technologii Java oraz testowania automatycznego. Prywatnie mąż, ojciec piątki dzieci.
Niektórym inżynierom/-kom w pewnym momencie przychodzi do głowy, że są traktowani jako podwykonawcy biznesu. Jeśli jest to klient wewnętrzny to inżynier jest dla biznes po prostu dostawca, a jeśli są w jednej organizacji, to IT jest dla biznesu wewnętrznym podwykonem. Tyle, że Ci inżynierowie/-ki chcą być dla klienta partnerem, nie podwykonem i nie wiedzą jak to zrobić.
Jeśli to, co wyżej napisałem w jakiś sposób odzwierciedla Twoje wewnętrzne przemyślenia, wpadnij na moją prezkę. Podam Ci kilka punktów, na które warto zwrócić uwagę, jeśli chcesz budować partnerską relację z biznesem.
Michał Bartyzel
Pracuję w branży IT od 20 lat jako programista, team leader, architekt, przedsiębiorca. Przez wiele lat pomagałem zespołom refaktoryzować kod, od jakiegoś czasu zajmuję się reorganizacją procesów dostarczania oprogramowania oraz usprawnianiem współpracy z klientem. Napisałem kilka książek min. “Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce?” i “Getting Things Programmed. Droga do efektywności”. Więcej o mnie i o mojej pracy dowiesz się na stronie https://michalbartyzel.pl
Forget about the spine-chilling tales of managing large–scale systems. It doesn’t have to be a daunting task. We’re here to advocate for battle’s proven simplicity with a pinch of fun. We’ll slice through the Gordian knot of complexity, juggle scalability patterns while uncovering their dark sides, and turn time modelling into a time-travel adventure.
No sale of silver bullets here; instead, we arm you with practical solutions and actionable strategies based on real-world examples and the dark sides of rapid-scaling problems.
Join us to transform your approach to evolving system architecture, leaving you with insights immediately applicable to your work.
Wojtek Ptak
Wojtek works as Head of Product Engineering at Revolut. Before, he worked as CTO for several companies, provided consulting, training, and assisted in building various data collecting, analytics, and applied ML/AI solutions, including Big Data implementations, data stream processing systems, and data insight projects.
He worked with multiple Forbes 500 brands in the US, UK, and the Netherlands, including The Coca-Cola Company, the American Bankers Association, Macy’s, Bloomingdales, Heineken, Saks 5th Avenue, BP, Boots, Polo Ralph Lauren, Porsche, HSBC, and others.
Konrad Kokosa
Założyciel https://crowdpub.org, na nowo definiujący sposób pisania i czytania książek. Współzałożyciel inicjatywy https://dotnetos.org mającej na celu nauczanie w obszarze .NET, w szczególności o wydajności aplikacji. Niezależny konsultant programujący od kilkunastu lat, prelegent konferencyjny i autor książki Pro .NET Memory Management. Sceptyczny fan technologii Web3 i blockchain. Microsoft MVP.
Od zera do wewnętrznej platformy developerskiej. Czyli przejście przez to czego potrzebujemy żeby na koniec mieć wewnętrzną platformę developerską. Jak uzyskać alignment w organizacji, jakie standardy zdefiniować i jak je wdrożyć? Jak wdrażać, monitorować i testować? Kubernetes, zarządzany Kubernetes, czy coś innego? Jak zabezpieczyć? Do czego dalej wykorzystać i jak rozwijać?
Szymon Warda
W IT od czasów kiedy Internet Explorer 6 uchodził za "lepszą" przeglądarkę. Po zrealizowaniu marzenia każdego informatyka, czyli stworzeniu gry, buduję systemy rozproszone. Pasjonat modelowania danych, ewolucyjnego podejścia do architektury i znajdywania balansu między rozwiązaniami białkowymi a technologicznymi. 1/2 PatoArchitektów.
Pewnie już dziesiątki razy słyszałeś/słyszałaś, że aplikacja ma być niezawodna, wysokodostępna, bla bla bla... że Google ma SRE i jest to super! Serio?!
W trakcie odczarujemy ten marketingowy bełkot i zdefiniujemy, co to w ogóle jest ta cała niezawodność. Do tego dorzucimy kilka dobrych rad, jak tego użyć w praktyce.
A crème de la crème sesji: jeżeli jesteś programistą, usłyszysz, co powiedzieć do adminów i DevOpsów, i vice versa ;-)
Łukasz Kałużny
Pracuje jako doradca technologiczny w zakresie strategii i architektury IT w Protopii, głównie związanych z technologiami chmurowymi i kontenerowymi - z Azure od 2013, Dockerem od 2014, a K8s - 2016/2017. Prowadzi podcast Patoarchitekci.io o technologii skierowany seniorów deweloperów, architektów IT. Od 2012 roku wyróżniany corocznie nagrodą Microsoft MVP.
DDD i jego pozytywy odmieniono już w prezentacjach chyba na wszystkie możliwe przypadki. „Wdrażanie” DDD często może być marszem ku klęsce, bo rzeczywistość nie jest już tak różowa jak na slajdach… Nie mówmy więc kolejny raz o roli i znaczeniu agregatów czy bounded-contextów, ale na konkretnych przykładach pokażmy, jakie pułapki tu czekają i jak można je skutecznie ominąć, aby uniknąć tytułowej porażki i kolejnych szram z Wietnamu.
Mariusz Gil
Software architect interesujący się złożonymi systemami o wysokiej wartości biznesowej, związany głównie z platformami webowymi. Ex-CTO, konsultant, speaker i trener w Bottega IT Minds. Z branżą IT związany od ponad 18 lat. Od kilku lat wykorzystuje EventStorming jako narzędzie do komunikacji pomiędzy zespołami developerskimi i biznesowymi, a także do modelowania oprogramowania w oparciu o DDD, CQRS czy EventSourcing. Uczestnik EventStorming Summit 2017, gdzie wspólnie z innymi zaproszonymi przez Alberto Brandoliniego osobami pracował nad rozwojem tej techniki. Po godzinach oddaje się swoim innym pasjom, fotografii i gitarze elektrycznej.
Mikrousługi już od dłuższego czasu nie są rzadkością na rynku - przez ten czas branża odkryła tysiące sposobów jak wdrażać je źle. Przykładowo: poprzez przywiązanie do starych nawyków przyjaznych monolitom, złych praktyk wdrożeniowych, groteskowej polityki bezpieczeństwa firmy itp.
Podczas tej prelekcji będziemy uczyć się na błędach innych i przypomnimy sobie najważniejsze wnioski wyciągnięte z udanych i nieudanych wdrożeń mikrousług. Skupimy się na kwestiach, które nie zostały poruszone w podobnych prezentacjach.
Grzegorz Piwowarek
Founding Engineer w Quesma, niezależny konsultant/trener, blogger (4comprehension.com). Interesują go systemy rozproszone, bebechy, wydajność i architektura systemów. Krążą plotki, że istnieje tylko w czasie kompilacji.
Startup's early days aren't easy: there are always too many topics on your plate and everything is of the highest priority. As a first-time CTO you have to pick your battles wisely - I'll try to help by sharing my experience as a former startup CTO and a person who cooperates with startups on daily basis. There is no single blueprint to follow, but we'll go through major decision points, key concerns to be addressed, most pressing questions to be answered. To illustrate the challenges covered and make it an interactive experience, we will create an artificial startup and take it for a virtual spin together.
Sebastian Gębski
Sebastian Gębski, jak sam się określa na swoim blogu "No Kill Switch" - engineering leader (at scale).
Zaprawiony w świecie IT w różnych miejscach i pozycjach, od mrocznego świata konsultingu, przez dynamiczny świat rosnących i upadających startupów, po architekturę w chmurze. Sebastian to nie tylko "No Kill Switch", ale też "no bullshit" podejście do technologii i organizacji. Niejedną organizację i technologię ma za kołnierzem, jasno wyraża swoje przemyślenia i nie bierze jeńców.
Jeżeli zastanawiacie się, kto przygotowuje nasze błyskotliwe pytania i riposty na spotkaniach Coffee, to człowiek, na którego powinniście spojrzeć.